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9, 2008. 
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I. REAL PARTY IN INTEREST 

The real party in interest is the Hewlett-Packard Development Company, L.P., a 
Texas Limited Partnership having its prmcipal place of business in Houston, Texas. The 
Hewlett-Packard Development Company, L.P„ is the assignee of the present application. 
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II. RELATED APPEALS AND INTERFERENCES 

On information and belief, there are no appeals, interferences, or judicial 
proceedings known to the appellant, the appellant's legal representative, or assignee 
which may be related to, directly affect or be directly affected by or have a bearing on the 
Board of Patent Appeals and Interferences (the "Board") decision in the pending appeal. 

III. STATUS OF CLAIMS 

A. Total Claims: 1-23 

B. Current Status of Claims: 



1. 


Claims canceled: 


none 


2. 


Claims withdrawn: 


none 


3. 


Claims pending: 


1-23 


4. 


Claims allowed: 


none 


5. 


Claims rejected: 


1-23 


6. 


Claims objected to: 


none 



C. Claims on Appeal: 1-23 

As indicated above, claims 1-23 are pending in this application, stand finally 
rejected, and are being appealed. These claims are rejected in the final office action 
mailed February 13, 2008 ("the last office action"). 

IV. STATUS OF AMENDMENTS 

No amendment has been filed after the final rejection. 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 

The claimed subject matter relates to networking and communications. More 
particularly, the claimed subject matter relates to automated router load balancing. 

Independent claim 1 relates to a method of load balancing between a plurality of 
routers by automated resetting of gateways. (Page 4, lines 13 through page 6, line 2; flow 
chart in FIG. 2.) A packet is received at a first router firom a source host to be forwarded 
to a destination host. (Page 4, lines 26-28; block 204 in FIG. 2.) An algorithm is applied 
at the first router to select a second router to be a next gateway for the source host for 
packets destined to the destination host. (Page 4, line 29 through page 5, line 12; block 
206 in FIG. 2.) Finally, an ICMP redirect message is sent from the first router to the 
source host to reset a default gateway of the source host to be the second router for 
packets destined to the destination host. (Page 5, lines 13-26; block 208 in FIG. 2.) 

Independent claim 7 relates to an apparatus for routing packets with a load 
balancing capability involving automated resetting of gateways. (Page 4, lines 13-17; 
Routers 106-x in FIG. 1 and flow chart in FIG. 2.) A receiver is configured to receive a 
packet from a source host to be forward to a destination host. (Page 4, lines 26-28; block 
204 in FIG. 2.) A selection module is configured to apply an algorithm to select another 
router to be a next gateway of the source host for packets destined to the destination host. 
(Page 4, line 29 through page 5, line 12; block 206 in FIG. 2.) Finally, a transmission 
module configured to send an ICMP redirect message to the source host to reset a current 
gateway of the source host to be said other router for packets destined to the destination 
host. (Page 5, lines 13-26; block 208 in FIG. 2.) 

Independent claim 17 relates to a method of load balancing between a plurality of 
routers by automated selection of a router to respond to an ARP request. (Page 6, lines 3 
through page 7, line 30; flow chart in FIG. 3.) An address resolution protocol (ARP) 
request is received at the plurality of routers from a requesting host from a source IP 
address in relation to a destination IP address. (Page 6, lines 27-28; see block 304 in FIG. 
3.) The automated selection of the router to respond to the ARP request is performed by 
applying an algorithm at each router to determine which single router is to respond to the 
ARP request. (Page 6, Unes 28-30; block 306 in FIG. 3.) Finally, an ARP reply is sent 
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from the responding router to the requesting host. (Page 7, lines 18-19; block 308 in FIG. 
3.) 

Independent claim 23 relates to a system of load balancing between a plurality of 
routers involving automated selection of a router to respond to an ARP request. (Page 6, 
lines 3 through page 7, line 30; flow chart in FIG. 3.) The system includes a means for 
receiving an address resolution protocol (ARP) request at the plurality of routers from a 
requesting host from a source IP address in relation to a destination IP address. (Page 6, 
lines 27-28; see block 304 in FIG. 3.) The system further includes a means for 
performing the automated selection of the router to respond to the ARP request by 
applying an algorithm at each router to determine which single router is to respond to the 
ARP request. (Page 6, lines 28 through page 7, line 17; block 306 in FIG. 3.) The 
system also includes a means for sending an ARP reply from the responding router to the 
requesting host. (Page 1, lines 18-19; block 308 in FIG. 3.) 

Applicant respectfully submits that independent claims 1, 7, and 17 do not include 
any means or step elements under the sixth paragraph of 35 U.S.C. § 1 12. 

Under the sixth paragraph of 35 U.S.C. § 1 12, independent claim 23 includes 
means for receiving an address resolution protocol (ARP) request at the plurality of 
routers from a requesting host from a source IP address in relation to a destination IP 
address. (Page 6, lines 27-28; see block 304 in FIG. 3.) Claim 23 ftirther includes a 
means for performing the automated selection of the router to respond to the ARP request 
by applying an algorithm at each router to determine which single router is to respond to 
the ARP request. (Page 6, lines 28 through page 7, line 17; block 306 in FIG. 3.) Claim 
23 also includes a means for sending an ARP reply from the responding router to the 
requesting host. (Page 7, lines 18-19; block 308 in FIG. 3.) 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The following grounds of rejection are to be reviewed on appeal: 

1. The rejection of claims 1 and 7 under 35 U.S.C. § 103 (a) as being 

unpatentable over Siev et al. (Pub. No. 2004/0071087) in view of Chung et al. (Pat. No. 

6,470,389). 
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2. The rejection of claims 2, 4, 5, 8, and 10-12 under 35 U.S.C. § 103 (a) as being 
unpatentable over Siev et al. (Pub. No. 2004/0071087) in view of Chung et al. (Pat. No. 
6,470,389) and fiirther in view of Inoue et al. (Pub. No. 2003/0108052). 

3. The rejection of claims 3, 6, 9, 13 and 15 under 35 U.S.C. § 103 (a) as being 
unpatentable over Siev et al. (Pub. No. 2004/0071087) in view of Chung et al. (Pat. No. 
6,470,389) and further in view of Datta et al. (Pat. No. 6,493,341). 

4. The rejection of claim 14 under 35 U.S.C. § 103 (a) as being unpatentable over 
Siev et al. (Pub. No. 2004/0071087) in view of Chung et al. (Pat. No. 6,470,389) and 
further in view of Datta et al. (Pat. No. 6,493,341) and further in view of Lamberton et al. 
(Pat. No. 7,003,581). 

5. The rejection of claim 16 under 35 U.S.C. § 103 (a) as being unpatentable over 
Siev et al. (Pub. No. 2004/0071087) in view of Chung et al. (Pat. No. 6,470,389) and 
further in view of Datta et al. (Pat. No. 6,493,341) and further in view of Inoue et al. (Pub. 
No. 2003/0108052). 

6. The rejection of claims 17-19 and 23 under 35 U.S.C. § 103 (a) as being 
unpatentable over Siev et al. (Pub. No. 2004/0071087) in view of Inoue et al. (Pub. No. 
2003/0108052). 

7. The rejection of claims 20-21 under 35 U.S.C. § 103 (a) as being unpatentable 
over Siev et al. (Pub. No. 2004/0071087) in view of hioue et al. (Pub. No. 2003/0108052) 
and further in view of Datta et al. (Pat. No. 6,493,341). 

8. The rejection of claim 20 under 35 U.S.C. § 103 (a) as being unpatentable over 
Siev et al. (Pub. No. 2004/0071087) in view of Inoue et al. (Pub. No. 2003/0108052) and 
further in view of Blair (Pat. No. 6,778,495). 
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VII. ARGUMENT 

Applicant respectfully traverses the aforementioned rejection of claims 1-23 in the 
latest office action for the following reasons. 

A. Claims 1-6 

Claim 1 stands rejected under 35 U.S.C. § 103 (a) as being unpatentable over Siev 
et al. (Pub. No. 2004/0071087) in view of Chung et al. (Pat. No. 6,470,389). Applicant 
respectfully traverses this rejection. 

Claim 1 recites as follows. 

1 . A method of load balancing between a plurality of routers by 
automated resetting of gateways, the method comprising: 
receiving a packet at a first router from a source host to be 

fonwarded to a destination host; 
applying an algorithm at the first router to select a second 

router to be a next gateway for the source host for packets 

destined to the destination host; and 
sending an ICMP redirect message from the first router to the 

source host to reset a default gateway of the source host 

to be the second router for packets destined to the 

destination host. 
(Emphasis added.) 

As shown above, claim 1 pertains to a technique for load balancing between a plurality of 
routers by automated resetting of gateways. A packet is received at a first router from a 
source host to be forwarded to a destination host. An algorithm is applied at a first 
router to select a second router to be a next gateway for the source host for packets 
destined to the destination host. Finally, claim 1 specifies that an ICMP redirect message 
is sent from the first router to the source host to reset a default gateway of the source 
host to be the second router for packets destined to the destination host. 
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1 . THE CITED ART DOES NOT TEACH OR SUGGEST "APPLYING AN 
ALGORITHM AT THE FIRST ROUTER TO SELECT A SECOND ROUTER 
TO BE A NEXT GATEWAY. ..." 

First, the latest office action asserts that Siev et al. discloses the claim element of 
"applying an algorithm at the first router to select a second router to be a next 
gateway for the source host for packets destined to the destination host." Applicant 
respectfully disagrees with this assertion. 

In regard to this claim element, the latest office action cites to paragraphs 0028 
through 0030, FIG. 1, and the abstract of Siev et al. As stated in paragraph 0028, "When 
a server enters into the Selecting Algorithm Mode 220 ... a message requesting to be a 
leader is broadcast on LAN 145. . .." (Emphasis added.) Thus, paragraph 0028 explains 
that the Selecting Algorithm Mode 220 of Siev is entered by a server, not the claimed 
router . That servers 110, 120, 130 are distinct and separate from routers 140, 170 is 
clearly shown in FIG. 1 of Siev et al. 

Furthermore in regard to this claim element, the Selecting Algorithm Mode 220 of 
Siev et al. is used to select a leader from amongst the servers. As stated in the abstract of 
Siev et al., "The leader acts as a load balancer for the group while the remaining servers 
act as slaves." Thus, the algorithm of Siev et al. is designed for and used for load 
balancing amongst a group of servers. In contrast, the claim element recites that the 
algorithm is applied "at the first router to select a second router to be a next gateway 
. . .." In other words, Siev et al. discloses selecting a leader for load balancing amongst 
a group of servers, not the claimed selection of a next gateway from amongst 
multiple routers. 

Chung et al. has not been cited in relation to this claim element. Applicant 
respectfully submits that the disclosure of Chung et al. does not cure the above-discussed 
deficiencies of Siev et al. in relation to claim 1 . 

2. THE CITED ART DOES NOT TEACH OR SUGGEST "SENDING AN 
ICMP REDIRECT MESSAGE ... TO RESET A DEFAULT GATEWAY OF 
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THE SOURCE HOST TO BE THE SECOND ROUTER FOR PACKETS 
DESTINED TO THE DESTINATION HOST." 

Second, as stated in the latest office action, Siev et al. does not disclose the claim 
element of "sending an ICMP redirect message jfrom the first router to the source host to 
reset a default gateway of the source host to be the second router for packets 
destined to the destination host." (Emphasis added.) Applicant agrees with this 
statement. 

The latest office action asserts that Chung et al. teaches this claim element. 
Applicant respectfully traverses this assertion. 

Applicant respectfully submits that the citation to Chung et al. teaches that ICMP 
redirect messages are undesirable and need to be suppressed . Specifically, as stated on 
column 8, lines 27-33, "However, this effect is undesirable in the routing technique of 
FIG. 4 because the dispatcher 64 performs the server selection process as previously 
described. It therefore may be necessary to suppress the ICMP host redirect message for 
the ghost IP address by, for example, removing or altering the corresponding operating 
system code in the dispatcher." (Emphasis added.) 

In addition, applicant respectfully submits that the ICMP message in Chung et al. 
is a redirect message for a ghost IP address. A ghost IP address is defined in Chung et al. 
as follows. "A 'ghost IP address' is one type of cluster address in the form of an IP 
address which is not used as a primary address for any server of a given server cluster." 
(Col. 5, lines 52-55.) In contrast, the claimed ICMP redirect message is sent fi-om the 
first router to the source router to reset a default gateway of the source host to be the 
second router for packets destined to the destination host. 

Therefore, for at least one of the above-discussed reasons, applicant respectfully 
submits that claim 1 overcomes this rejection. 

Claims 2, 4, and 5 were rejected under 35 U.S.C. § 103 as being unpatentable 
over Siev et al. in view of Chung et al. in further view of Inoue et al. Applicant 
respectfully traverses this rejection in relation to these claims. 
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Claims 2, 4, and 5 depend from claim 1. Hence, applicant respectfully submits 
that claims 2, 4, and 5 are also patentable over Siev et al. in view of Chung et al. for at 
least the same reasons discussed above in relation to claim 1. Inoue et al. is cited in 
relation to a pseudo-random algorithm, and this citation does not cure the above- 
discussed deficiencies of Siev et al. and Chung et al. Therefore, claims 2, 4, and 5 also 
overcome this rejection. 

Claims 3 and 6 were rejected under 35 U.S.C. § 103 as being unpatentable over 
Siev et al. in view of Chung et al. in further view of Datta et al. Applicant respectfiilly 
traverses this rejection in relation to these claims. 

Claims 3 and 6 depend from claim 1 . Hence, applicant respectfully submits that 
claims 3 and 6 are also patentable over Siev et al. in view of Chung et al. for at least the 
same reasons discussed above in relation to claim 1 . Datta et al. is cited in relation to a 
roimd robin type selection process, and this citation does not cure the above-discussed 
deficiencies of Siev et al. and Chimg et al. Therefore, claims 3 and 6 also overcome this 
rejection. 

B. Claims 7-16 

Claim 7 stands rejected under 35 U.S.C. § 103 (a) as being unpatentable over Siev 
et al. (Pub. No. 2004/0071087) in view of Chung et al. (Pat. No. 6,470,389). Applicant 
respectfully traverses this rejection. 

Apparatus claim 7 recites similar claim elements to method claim 1. Claim 7 
pertains to an apparatus for routing packets. The apparatus includes "a selection module 
configured to apply an algorithm to select a next gateway of the source host for 
packets destined to the destination hosf . (Emphasis added.) The apparatus further 
includes "a transmission module configured to send an ICMP redirect message to the 
source host to reset a current gateway of the source host for packets destined to the 
destination host." (Emphasis added.) 
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1 . THE CITED ART DOES NOT TEACH OR SUGGEST "A SEARCH 
MODULE CONFIGURED TO APPLY AN ALGORITHM TO SELECT A 
NEXT GATEWAY...." 

First, the latest office action asserts that Siev et al. discloses the claim element of 
includes "a selection module configured to apply an algorithm to select a next gateway 
of the source host for packets destined to the destination host". (Emphasis added.) 
Applicant respectfully disagrees with this assertion. 

In regard to this claim element, the Selecting Algorithm Mode 220 of Siev et al. is 
used to select a leader from amongst the servers. As stated in the abstract of Siev et al., 
"The leader acts as a load balancer for the group while the remaining servers act as 
slaves." Thus, the algorithm of Siev et al. is designed for and used for load balancing 
amongst a group of servers. In contrast, the claim element recites that the algorithm is 
appUed "at the first router to select a second router to be a next gateway . . .." 
(Emphasis added.) In other words, Siev et al. discloses selecting a leader for load 
balancing amongst a group of servers, not the claimed selection of a next gateway 
from amongst multiple routers. 

Chung et al. has not been cited in relation to this claim element. Applicant 
respectfully submits that the disclosure of Chung et al. does not cure the above-discussed 
deficiencies of Siev et al. in relation to claim 7. 

2. THE CITED ART DOES NOT TEACH OR SUGGEST "A 
TRANSMISSION MODULE CONFIGURED TO SEND AN ICMP REDIRECT 
MESSAGE TO RESET A DEFAULT GATEWAY ...." 

Second, as stated in the latest office action, Siev et al. does not discloses the claim 
element of "a transmission module configured to send an ICMP redirect message to the 
source host to reset a current gateway of the source host for packets destined to the 
destination host." (Emphasis added.) Applicant agrees with this statement. 

The latest office action asserts that Chung et al. teaches this claim element. 
Applicant respectfully traverses this assertion. 
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First, applicant respectfully submits that the citation to Chung et al. teaches that 
ICMP redirect messages are undesirable and need to be suppressed . Specifically, as 
stated on column 8, lines 27-33, "However, this effect is undesirable in the routing 
technique of FIG. 4 because the dispatcher 64 performs the server selection process as 
previously described. It therefore may be necessary to suppress the ICMP host redirect 
message for the ghost IP address by, for example, removing or altering the corresponding 
operating system code in the dispatcher." (Emphasis added.) 

Second, applicant respectfully submits that the ICMP message in Chung et al. is a 
redirect message for a ghost IP address. A ghost IP address is defined in Chung et al. as 
follows. "A 'ghost IP address' is one type of cluster address in the form of an IP address 
which is not used as a primary address for any server of a given server cluster." (Col. 5, 
Unes 52-55.) In contrast, the claimed ICMP redirect message is sent from the first router 
to the source router to reset a default gateway of the source host to be the second 
router for packets destined to the destination host. 

Therefore, for at least one of the above-discussed reasons, applicant respectfully 
submits that claim 7 overcomes this rejection. 

Claims 8 and 10-12 were rejected under 35 U.S.C. § 103 as being unpatentable 
over Siev et al. in view of Chung et al. in further view of Inoue et al. Applicant 
respectfully traverses this rejection in relation to these claims. 

Claims 8 and 10-12 depend from claim 7. Hence, applicant respectfully submits 
that claims 8 and 10-12 are now also patentable over Siev et al. in view of Chimg et al. 
for at least the same reasons discussed above in relation to claim 7. Inoue et al. is cited in 
relation to a pseudo-random algorithm, and this citation does not cure the above- 
discussed deficiencies of Siev et al. and Chung et al. Therefore, claims 8 and 10-12 also 
overcome this rejection. 

Claims 9, 13 and 15 were rejected under 35 U.S.C. § 103 as being unpatentable 
over Siev et al. in view of Chung et al. in further view of Datta et al. Applicant 
respectfully traverses this rejection in relation to these claims. 
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Claims 9, 13 and 15 depend from claim 7. Hence, applicant respectfully submits 
that claims 9, 13 and 15 are now also patentable over Siev et al. in view of Chung et al. 
for at least the same reasons discussed above in relation to claim 7. Datta et al. is cited in 
relation to a round robin type selection process, and this citation does not cure the above- 
discussed deficiencies of Siev et al. and Chung et al. Therefore, claims 9, 13 and 15 also 
overcome this rejection. 

Claim 14 was rejected under 35 U.S.C. § 103 as being impatentable over Siev et 
al. in view of Chung et al. further in view of Datta et al. and further in view of Lamberton 
et al. Applicant respectfully traverses this rejection in relation to this claim. 

Claim 14 depends from claim 7. Hence, applicant respectfully submits that 
claims claim 14 is also patentable over Siev et al. in view of Chung et al. for at least the 
same reasons discussed above in relation to claim 7. Datta et al. is cited in relation to a 
rotmd robin type selection process, and this citation does not cure the above-discussed 
deficiencies of Siev et al. and Chung et al. Lamberton et al. is cited in relation to a 
weighted has algorithm, and this citation also doe not cure the above-discussed 
deficiencies of Siev et al. and Chung et al. Therefore, claim 14 also overcomes this 
rejection. 

Claim 16 was rejected under 35 U.S.C. § 103 as being unpatentable over Siev et 
al. in view of Chung et al. further in view of Datta et al. and further in view of Inoue et al. 
Applicant respectfully traverses this rejection in relation to this claim. 

Claim 16 depends from clahn 7. Hence, applicant respectfully submits that 
claims claim 16 is also patentable over Siev et al. in view of Chung et al. for at least the 
same reasons discussed above in relation to claim 7. Datta et al. is cited in relation to a 
round robin type selection process, and this citation does not cure the above-discussed 
deficiencies of Siev et al. and Chung et al. Inoue et al. is cited in relation to a pseudo- 
random algorithm, and this citation also does not cure the above-discussed deficiencies of 
Siev et al. and Chung et al. Therefore, claim 16 also overcomes this rejection. 

C Claims 17-23 
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Claims 17-19 were rejected under 35 U.S.C. § 103 as being unpatentable over 
Siev et al. in view of Inoue et al. Applicant respectfully traverses this rejection in relation 
to these claims. 

Claim 17 recites as follows. 

17. A method of load balancing between a plurality of routers by automated 
selection of a router to respond to an ARP request, the method comprising: 
receiving an address resolution protocol (ARP) request at the plurality of routers 

jfrom a requesting host from a source IP address in relation to a destination 

IP address; 

performing the automated selection of the router to respond to the ARP request by 
applying an algorithm at each router to determine which single router is 
to respond to the ARP request; and 

sending an ARP reply from the responding router to the requesting host. 

(Emphasis added.) 

As shovm above, the claimed invention now expressly recites in the second element 
(outside the preamble) "performing the automated selection of the router to respond to 
the ARP request by applying an algorithm at each router to determine which single 
router is to respond to the ARP request". 

In Siev et al., "One of the servers is elected as a leader (the Master), which acts 
as a load balancer for the group, while the remaining servers act as slaves." (Paragraph 
[0008], emphasis added.) Furthermore, Siev et al. teaches that "the leader determines 
whether the requested IP address belongs to a remote client 150 of the server farm or it is 
one of the joint IP addresses. If not, the leader ignores the request. If yes, the leader 
checks whether this IP address has already been assigned to one of the servers. ..." 
(Paragraph [0041], emphasis added.) Thus, the algorithm of Siev et al. is designed for 
and used to determine a Master load balancing amongst a group of servers. 

In contrast, the claim element recites that the algorithm is applied "at each router 
to determine which single router is to respond to the ARP request" (Emphasis added.) In 
other words, while Siev et al. discloses an algorithm to determine a Master server for 
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load balancing amongst a group of servers, the claimed method does not pertain to 
servers. Instead, the claimed method pertains to routers and includes applying an 
algorithm at each router. 

In other words, claim 17 teaches an inventive use of ARP requests and replies to 
implement the load balancing by the routers themselves as peers. Regarding Inoue et al., 
that citation merely discloses ARP requests and replies, but it does noldisclose or suggest 
the claimed method where the load balancing is performed by applying an algorithm at 
each router to determine which single router is to respond to the ARP request. 

Therefore, applicant respectfully submits that amended claim 17 is patentably 
distinguished over Siev et al. in view of Inoue et al. 

Claims 18-19 depend from claim 17. Hence, applicant respectfully submits that 
these claims are also patentably distinguished over the cited art. 

Claim 20 was rejected under 35 U.S.C. § 103 as being unpatentable over Siev et 
al. in view of Inoue et al., as applied to claim 19 above, in further view of Blair. 
Applicant respectfully traverses this rejection. 

Claim 20 depends from claim 17. Hence, applicant respectfully submits that 
claim 20 is also patentable over Siev et al. in view of Inoue et al. for at least the same 
reasons discussed above in relation to claim 17. The disclosure of Blair does not cure the 
above-discussed deficiencies of Siev et al. and Inoue et al. 

Claims 21-22 were rejected under 35 U.S.C. § 103 as being unpatentable over 
Siev et al. in view of Inoue et al. in further view of Datta et al. Applicant respectfiilly 
traverses this rejection. 

Claims 21-22 depends from claim 17. Hence, applicant respectfully submits that 
claims 21-22 are also patentable over Siev et al. and Inoue et al. for at least the same 
reasons discussed above in relation to claim 17. Datta et al. is cited in relation to a round 
robin type selection process and communicating load levels. The disclosure of Datta et 
al. does not cure the above-discussed deficiencies of Siev et al. and Inoue et al. 
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Claim 23 has means elements which correspond to the elements of claim 17. 
Hence, applicant respectfully submits that claim 23 is also patentably distinguished over 
the cited art for the same reasons as discussed above in relation to claim 17. 



VIII. CONCLUSION 

For at least the above reasons, applicant respectfully requests that the rejections of 
claims 1-23 be overturned. 

Respectfully submitted, 
Michael Roeder 



Dated: June 25. 2008 /James K. Qkamoto. Reg. No. 40.1 10/ 

James K. Okamoto, Reg. No. 40,1 10 
Okamoto & Benedicto LLP 
P.O. Box 641330 
San Jose, CA95164 
Tel.: (408)436-2110 
Fax.: (408)436-2114 
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CLAIMS APPENDIX 
CLAIMS INVOLVED IN THE APPEAL 

1 . A method of load balancing between a plurality of routers by automated 
resetting of gateways, the method comprising: 

receiving a packet at a first router from a source host to be forwarded to a 
destination host; 

applying an algorithm at the first router to select a second router to be a 
next gateway for the source host for packets destined to the 
destination host; and 

sending an ICMP redirect message from the first router to the source host 
to reset a default gateway of the source liost to be the second 
router for packets destined to the destination host. 

2. The method of claim 1 , wherein the algorithm comprises a pseudo-random 
algorithm. 

3. The method of claim 1 , wherein the algorithm selects the next default 
gateway using a round robin type selection process. 

4. The method of claim 1 , wherein the algorithm comprises a hash function, 
wherein an output of the hash function returns an index of a router to be 
used to route subsequent packets with a same hash value. 

5. The method of claim 4, wherein the hash function is a function of any 
combination of the IP addresses of the destination and source hosts of the 
packet. 

6. The method of claim 1 , wherein the algorithm is load based, and further 
comprising communicating load levels amongst the plurality of routers. 
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7. An apparatus for routing packets with a load balancing capability involving 
automated resetting of gateways, the apparatus comprising: 

a receiver configured to receive a packet from a source host to be fonward 

to a destination host; 
a selection module configured to apply an algorithm to select another 

router to be a next gateway of the source host for packets destined 

to the destination host; and 
a transmission module configured to send an ICMP redirect message to 

the source host to reset a current gateway of the source host to be 

said other router for packets destined to the destination host. 

8. The apparatus of claim 7, wherein the selection module comprises a 
pseudo-random number generator. 

9. The apparatus of claim 7, wherein the selection module applies a round- 
robin type algorithm to select the next gateway. 

1 0. The apparatus of claim 7, wherein the selection module applies a hash 
function. 

1 1 . The apparatus of claim 1 0, wherein the hash function is a function of a 
source IP address. 

12. The apparatus of claim 10, wherein the hash function is a function of a 
combination of the source and destination IP addresses. 

13. The apparatus of claim 7, wherein the apparatus is configured to 
communicate load levels to and receive load levels from other routing 
apparatus, and wherein the selection module applies a load-based 
algorithm. 
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14. The apparatus of claim 13, wherein the load-based algorithm comprises a 
weighted hash algorithm. 

1 5. The apparatus of claim 1 3, wherein the load-based algorithm comprises a 
weighted round robin algorithm. 

16. The apparatus of claim 13, wherein the load-based algorithm comprises a 
pseudo-random algorithm. 

1 7. A method of load balancing between a plurality of routers by automated 
selection of a router to respond to an ARP request, the method 
comprising: 

receiving an address resolution protocol (ARP) request at the plurality of 
routers from a requesting host from a source IP address in relation 
to a destination IP address; 

performing the automated selection of the router to respond to the ARP 
request by applying an algorithm at each router to determine which 
single router is to respond to the ARP request; and 

sending an ARP reply from the responding router to the requesting host. 

1 8. The method of claim 1 7, further comprising forwarding a packet from the 
source IP address to the destination IP address. 

1 9. The method of claim 17, wherein the algorithm comprises a hash function. 

20. The method of claim 19, wherein the hash function is a function of the 
source and destination IP addresses. 

21 . The method of claim 17, wherein the algorithm determines the responding 
router using a round robin type selection process. 
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22. The method of claim 17, wherein the algorithm is load based, and further 
comprising communicating load levels amongst the plurality of routers. 

23. A system of load balancing between a plurality of routers involving 
automated selection of a router to respond to an ARP request, the system 
comprising: 

means for receiving an address resolution protocol (ARP) request at the 
plurality of routers from a requesting host from a source IP address 
In relation to a destination IP address; 

means for performing the automated selection of the router to respond to 
the ARP request by applying an algorithm at each router to 
determine which single router is to respond to the ARP request; 
and 

means for sending an ARP reply from the responding router to the 
requesting host. 
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EVIDENCE APPENDIX 
There are no documents or items submitted under this section. 
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RELATED PROCEEDINGS APPENDIX 
There are no documents or items submitted under tJiis section. 



